ci(release-rust): shim clang for ring .S asm under cargo-xwin (unblocks aarch64-pc-windows-msvc) - #98
Merged
Merged
Conversation
cargo-xwin compiles C with clang-cl, but cc-rs falls back to the GNU clang driver to assemble crates shipping GNU .S files (e.g. ring's aarch64 asm), inheriting clang-cl's /imsvc MSVC-include flags that the GNU driver rejects. This blocked aarch64-pc-windows-msvc cross-builds (and could surface as long hangs). Add a clang shim (gated on use_xwin) that rewrites each /imsvc token to -isystem and execs the real clang. clang-cl (used for C) is not shadowed, so NEON codegen for zstd/blake3 stays correct. Harmless for x86_64. Validated: kache aarch64-pc-windows-msvc now cross-builds from clean in ~1m with ring as the rustls provider.
jleni
added a commit
to kunobi-ninja/kache
that referenced
this pull request
Jun 5, 2026
…ows deps aarch64-pc-windows-msvc had never produced an artifact (it hung on aws-lc-sys's cmake build, then was cancelled). Two fixes make it build: - aws-lc-sys is replaced by ring (separate commit), removing the cmake hang. ring's x86_64 asm uses nasm; its aarch64 asm uses GNU .S files. - cargo-xwin assembles those .S files with the GNU clang driver but feeds it clang-cl's /imsvc flags, which it rejects. _workflows@v9 now ships a clang shim that rewrites /imsvc -> -isystem (Zondax/_workflows#98). The Windows build no longer needs perl/cmake (aws-lc-sys-only deps); ring needs only nasm. Trim the toolchain gate accordingly.
Member
Author
|
Cut |
jleni
added a commit
to kunobi-ninja/kache
that referenced
this pull request
Jun 6, 2026
…257) * deps: drop aws-lc-sys, use ring as rustls crypto provider aws-lc-sys's cmake/NASM C build hangs cross-compiling to aarch64-pc-windows-msvc under cargo-xwin (CI job cancelled after 44min). aws-lc-sys entered only as the rustls crypto provider — sigv4a uses pure-Rust p256, not aws-lc — so switching every rustls consumer to ring removes it entirely: - aws-sdk-s3: drop default-https-client (it hard-wires rustls-aws-lc on aws-smithy-runtime); inject a ring-backed Smithy client in remote.rs. - aws-config: default-features=false for the same reason; inject the same client into the credential-resolution path. - aws-smithy-http-client: rustls-ring (modern rustls 0.23 + ring), NOT legacy-rustls-ring (pins vulnerable rustls 0.21). - reqwest: rustls-no-provider + a process-default ring CryptoProvider installed in planner_client. - blake3: pure feature on Windows targets (its arm64 NEON C does not cross-compile under cargo-xwin). Result: x86_64-pc-windows-msvc cross-builds from macOS in ~2min with no aws-lc-sys in the tree; 657 native tests pass. * ci: keep aarch64-pc-windows-msvc via _workflows clang shim; trim Windows deps aarch64-pc-windows-msvc had never produced an artifact (it hung on aws-lc-sys's cmake build, then was cancelled). Two fixes make it build: - aws-lc-sys is replaced by ring (separate commit), removing the cmake hang. ring's x86_64 asm uses nasm; its aarch64 asm uses GNU .S files. - cargo-xwin assembles those .S files with the GNU clang driver but feeds it clang-cl's /imsvc flags, which it rejects. _workflows@v9 now ships a clang shim that rewrites /imsvc -> -isystem (Zondax/_workflows#98). The Windows build no longer needs perl/cmake (aws-lc-sys-only deps); ring needs only nasm. Trim the toolchain gate accordingly. * ci: bump _workflows to @v10 (cargo-xwin clang shim for aarch64-windows) v10 = v9 + the clang /imsvc->-isystem shim (zondax/_workflows@v10), which ring's aarch64 .S asm needs under cargo-xwin. Cut as a clean tag off v9 so no unrelated _workflows changes ride along.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
cargo-xwincross-builds-pc-windows-msvcusing clang-cl for C/C++. Butcc-rsfalls back to the GNUclangdriver to assemble crates that ship GNU.Sfiles — notablyring's aarch64 asm (armv8-mont-win64.S,p256-armv8-asm-win64.S, …). That fallback inherits clang-cl's/imsvcMSVC-include flags, which the GNU driver rejects:This makes
aarch64-pc-windows-msvcimpossible to cross-build for any Rust project depending on ring (rustls-with-ring, etc.). Inkacheit manifested as the arm64-Windows release job hanging 44min then cancelling (the hang was aws-lc-sys; removing it surfaced this clang issue underneath).Fix
A small step (gated on
matrix.use_xwin) installs aclangshim onPATHthat rewrites each/imsvctoken to-isystem(the GNU-driver spelling) and execs the real clang. It resolves the real clang by scanningPATHfor the firstclangoutside its own dir, so it's self-contained.clang-clis NOT shadowed — C/C++ compiles still go through the real clang-cl, so NEON codegen forzstd-sys/blake3stays correct (the GNU driver miscompiles arm64-Windows NEON; clang-cl doesn't)..Spath isn't hit; the shim is a transparent passthrough.Validation
Cross-compiled
kache(rustls + ring, no aws-lc-sys) from macOS via cargo-xwin:aarch64-pc-windows-msvc→ ✅ clean build, ~1m11s, real ARM64 PE producedx86_64-pc-windows-msvc→ ✅ unaffected, ~1m12sRollout
kachepins@v9. Once this merges, please retagv9(or cut the next major) so consumers pick it up — kache'saarch64-pc-windows-msvcrelease depends on it.